1.1 Field of the Invention
The present invention relates to means and a method for improving the robustness and ease-of-use of Workflow-Management-Systems or a computer system with comparable functionality (WEMS) related to the signaling of events.
1.2 Description and Disadvantages of Prior Art
A new area of technology with increasing importance is the domain of Workflow-Management-Systems (WFMS). WFMS support the modeling and execution of business processes. Business processes executed within a WEMS environment control who will perform which piece of work of a network of pieces of work and which resources are exploited for this work. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
The product “IBM MQSeries Workflow” (previously called IBM FlowMark) represents such a typical modern, sophisticated, and powerful workflow management system. It supports the modeling of business processes as a network of activities. This network of activities, the process model, is constructed as a directed, acyclic, weighted, colored graph. The nodes of the graph represent the activities, which are performed. The edges of the graph, the control connectors, describe the potential sequence of execution of the activities. Definition of the process graph is via IBM MQSeries Workflow's Flow Definition Language (FDL) or via the built-in graphical editor.
The runtime component of the Workflow-Management-System uses said process model as a template to create process instances. Each process instance is associated with a set of values, typically called the context. Said values are either supplied by the requestor of the process instance via the appropriate request or retrieved by programs that implement the various activities or are the result of the execution history of a certain process instance. The context is unique to a certain process instance. A particular important piece of information within said context is the process instance identifier that uniquely identifies a process instance. It should be noted that typically process instance identifiers are only unique within the set of process instances that are derived from a particular process model.
Particular important types of activities are event activities. An event activity provides the capability to have a process instance waiting until signaled. The signal, or in other words the event, may be created within the WFMS but typically will have its source in the outside of the workflow management system. Upon receiving said signal, the workflow management system stores the supplied information as context information (in this case into the output container of the event activity) and continues navigation.
Signaling the event is done via an appropriate signal request to the workflow management system. Said signal request may be created by a program exploiting the application-programming interface offered by the workflow management system or by sending an appropriate workflow management system defined message to the workflow management system that can typically carry such a signal request. Independently of how signaling is done, the signaling request must contain the appropriate process instance identifier of the process instance in which the event is waiting as well as the identification of the event. This information is necessary so that the workflow management system can locate the correct process instance and the correct event within the process model. If the issuer of the signaling request does not know the event identification or even does not know the process instance identifier, the issuer must obtain this information. To facilitate this the workflow management provides query capabilities that allow the issuer to query the input container of the-event activity. It is the responsibility of the process modeler to make sure that the input container of the event activity contains the appropriate values from which the process instance identification can be derived.
This state-of-the-art approach has several deficiencies, in particular when an event is signaled by sending a message to the workflow management system:                The signaler of the event must indicate to the workflow management system that the request is for signaling an event; that means the requester must follow the message structure defined by the workflow management system. This structure typically mandates to have certain indicators, such as the command that the message represents, in certain places of the message; for example the text string signal as the first field of the message. This mandates that an existing message-oriented signaler program must be adapted when the signal should now be processed by a workflow management system; an approach that is not always possible to implement. Another approach to overcome this situation is the usage of a translation program that translates the signaler's original message into the workflow management specific message; an approach that increases not only the complexity of the overall system (making maintenance and system management much more complicated) but also decreases performance for generating a signal.        The signaler must maintain the process instance identifier of the target process instance. If this is not possible, the signaler must obtain appropriate information (data in the input container of the event) from the workflow management system. This requires that the signaler already knows the name of the event so that it can set up the appropriate query to the workflow management system. This has the disadvantage that every change made to the process model such as changing the name of the event requires re-programming on the signaler's part (such as adapting the new name of the event).        The signaler must know the name (according to the nomenclature of the WEMS) of the event even if it knows the process instance identifier. Knowing the name includes knowing to some extent the structure of the process model; for example the process model could use the same name multiple times within the same process model, a situation that can easily arise when one synthesizes more, complex process models from simpler process models.        
The above listed deficiencies make it obvious that the current state of the art enforces a tight coupling between the signaler of an event and the workflow management system manifested by the information that the signaler must maintain about information that the workflow management system maintains. This situation is quite undesirable for the reasons outlined above. It should be possible to specify in the workflow management system all information necessary to process an almost arbitrary message for signaling an event. Further it should be possible for an arbitrary signaling of events to send signaling events to a WFMS without said signal being adapted to WEMS requirements. The arbitrary signaler should allowed to be unaware of the concrete nature of the consumer (that is the addressee) of the signaling requests. Then it is possible that the signaler can be developed independently from the consumer of the signaling request.
The weakness of the state-of-the-art approaches with respect to this problem area becomes even more distinct if one thinks of typical Internet scenarios commonly summarized by terms like C2B (Consumer-to-Business) or B2B (Business-to-Consumer) business processes. In these scenarios, it is obvious that the tight coupling of signaler to the workflow management system is not desirable at all.
1.2 Objective of the Invention
The invention is based on the objective to eliminate the need for event signalers to maintain information that is needed to locate the appropriate event in the appropriate process instance waiting for notification of said event.